home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 594 < prev    next >
Encoding:
Text File  |  1996-08-06  |  3.6 KB  |  92 lines
  1. Newsgroups: comp.std.c
  2. Path: in2.uu.net!bast!wattres!steve
  3. From: Adrian P Stephens <aps@symbionics.co.uk>
  4. Subject: Re: Prefixing functions with return type..
  5. Sender: Steve Watt -- KD6GGD <steve@watt.com>
  6. References: <4hstf8$jf3@cybernews.cyberus.ca> <1996Mar14.080731.15076@Watt.COM>
  7. Organization: Symbionics Ltd
  8. Message-ID: <1996Mar18.201616.6958@Watt.COM>
  9. Date: Mon, 18 Mar 96 20:16:16 GMT
  10.  
  11. [ posted for aps@symbionics.com by steve@Watt.COM ]
  12.  
  13. To: Steve Watt -- KD6GGD <steve@Watt.COM>
  14. From: Adrian P Stephens <aps@symbionics.co.uk>
  15. Date: Mon, 18 Mar 1996 12:41:43 +0000
  16.  
  17. (Steve,  please could you post this to comp.std.c for me,  my news out
  18.  feed is broken.  Thankx.)
  19.  
  20.  
  21. Steve Watt -- KD6GGD wrote:
  22. > 
  23. > In article <4hstf8$jf3@cybernews.cyberus.ca> robert_mohid@cyberus.ca (Robert Mohid) writes:
  24. > >I've been recently told that the practice of prefixing functions to
  25. > >indicate return type (ie: int iGetInt(void)   ) is "part of a new
  26. > >approach in progrmming". Can anyone confirm/deny this? I am extremely   <<++>>
  27. > >skeptical about that last statement, and to any who would reply
  28. > >*please* include some references as to make your claims as irrefutable
  29. > >as possible.   Thanks in advance.
  30. > 
  31. > Well, it's a slightly newish thing.  Microsoft decided to use it(*) in
  32. > their Windows code.  Many (many many!) people think it makes the names
  33. > much harder to read -- if I wanted to look at names with lots of type
  34. > information in them, I'd look at the output of a C++ translator.
  35.  
  36. Love them or loath them,  standards are important to any company.  Ours
  37. has "C" coding standards which require this kind of thing.   Initially
  38. I was against it,  because it makes things cluttered,   lengthens lines
  39. of code and makes for more typing.
  40.  
  41. Our standards also require explicit
  42. identification of the size returned if it is an integer.   This is of 
  43. benefit if you are doing emulation/debugging without a symbolic emulator/
  44. debugger (and how many do that??),   but otherwise doesn't allow you to
  45. pretend you've got "opaque types" in "C".   Also,  for some things where
  46. the type is not selected until compile time (e.g. integer sizes and 
  47. size_t particularly) you cannot select a name which is legal in the
  48. sense of these standards.
  49.  
  50. Here's an example from a bit of code I'm working on now:
  51.  
  52. extern TX_MANAGEMENT_PKT * psTxManagementPktTXP_NewTxBeaconPkt(void);
  53.  
  54. Elements required in our standard:
  55.  
  56.    TX_MANAGEMENT_PKT  - all upper case because it's a typedef/struct
  57.    p                  - pointer to ...
  58.    sTxManagementPkt   - a structure of this type (but case converted)
  59.    TXP                - name of module containing global export
  60.    "NewTxBeaconPkt"   - What I orginally called the routine before
  61.                       - I read our coding standards.
  62.  
  63.  
  64. Oh,  and finally another example from real code:
  65.  
  66. /*--------------------------------------------------------------------------
  67.  * Routine:     u32GetU32
  68.  *
  69.  * Parameters: Name         r/w     Usage
  70.  *              char **     *w      ppcParams
  71.  *                                  
  72.  * Returns:    u32 value
  73.  *
  74.  * Description:
  75.  *      Read and return a u32 value from the command-line,  reading decimal
  76.  *      numbers by default,  or hex if preceded by "0x".
  77.  *--------------------------------------------------------------------------*/
  78. extern u32 u32GetU32(char ** ppcParams);
  79.  
  80. Which,  I guess,  answers "<<++>>" above.
  81.  
  82.  
  83. > [snip] 
  84.  
  85. Adrian P Stephens
  86.  
  87. aps@symbionics.co.uk            Symbionics  Ltd
  88. Tel: +44 1223 421025 (work)     St John's Innovation Park
  89.                                 Cowley Road
  90.                                 Cambridge CB4 4WS,    UK
  91. ---------------------------------------------------------
  92.